Technical Field
The present disclosure relates generally to undo and redo operations, and more specifically to techniques for implementing undo and redo operations using patchsets or changesets.
Background Information
Relational databases are electronic databases that store related data in tables of rows and columns, and allow links to be established between tables that have matching fields, such that multiple tables may be simultaneously queried. Many relational data-bases utilize a version of the SQL language, a special-purpose programming language adapted to manage data storage. SQL statements may be executed by a relational data-base system implemented by a self-contained programming library integrated within an application. For example, SQL statements may be executed by the SQLite® embedded SQL database system, available in the public domain. Alternatively, SQL statements may be executed by a relational database system that executes as a separate process and is accessed by an application. For example, SQL statements may be executed by a MySQL® database system available open source, an Oracle Database available from Oracle Corp., or a Microsoft SQL Server database system available from Microsoft Corp.
Among other uses, relational database systems (e.g., SQL database systems) may be used to store application data (e.g., computer aided design (CAD) data) for software applications (e.g., CAD applications), operating as a standardized persistence format for the application data. For example, in a CAD application, when a project is initially designed, the CAD application may create a set of tables having rows that store elements, models, and other information related to the project. In response to changes to the project by the CAD application, the rows of the data tables may be changed, for example, to add rows, remove rows or modify rows.
Storing application data using a relational database system may have advantages over other storage approaches. For example, by using a relational database as a standardized persistence format, independent from the particular memory layout employed by the application, greater interoperability and opportunity for data reuse may be provided. In particular, applications that store data originating from multiple domains (such as certain CAD applications) may especially benefit, as it may enable schemas to be created and modified independent of the application that originally created the data.
While storing application data using a relation database may have benefits, it does present various problems. Some of these problems stem from a difference between how application data is persistently stored to a relational database and how in-memory copies of the application data are maintained. An application may no longer have a complete view of how its data is written to persistent storage. One manifestation of this problem can be seen in the implementation of undo and redo operations.
Many applications (including many CAD applications) enable a user to undo (i.e. reverse) a recent set of changes by triggering an undo operation in the user interface of the application. Subsequently, if they so desire, the user may redo (i.e. reinstate) the set of changes by triggering a redo operation in the user interface. With conventional applications that manage their own persistent storage of data, undo and redo operations may be implemented rather simply. The application can journal each of the changes it writes to persistent storage in binary objects (e.g., “undo blobs” or “redo blobs”). To implement an undo or redo operation, the application interprets the appropriate blob, and reverses or reinstates the writes it made to persistent storage.
However, when a relational database (e.g., an SQL database) is used as the persistence format, these techniques are typically not available. The statements the application sends to the relational database system often do not describe all the modifications made by the relational database system to the data. For example, the application may send a statement to the relational database system to delete all rows of a particular table that are more recent than a particular date (e.g., in SQL, a statement such as DELETE FROM table 2 WHERE date>?). Such a statement may cause many rows (e.g., 1000's of rows) to be deleted from the particular table. However, if the application simply journals the statement, it will not retain a record of the actual modifications made by the relational database system (e.g., the actual rows deleted), and will not be able to reverse the changes.
Accordingly, there is a need for an efficient and effective technique for implementing undo and redo operations in an application that utilizes a relational database as its persistence format.